Enterprise applications need to contact people and have requirements for how the contact is done and what responses, if any, are collected. For example, applications may need to contact all people who have certain interests, or a particular list of people or a single person. Applications may need to contact someone immediately in a crisis or they may want to remind someone of a task at an appropriate time. Enterprise applications also have requirements about what to do when the contact is unsuccessful, where success is something defined by the enterprise.
Recipients, on the other hand, have their own preferences about how and when they are contacted. For example, recipients may want particular people, such as a boss or family member, or people who represent particular interests, such as an executive from a Fortune 500 Company, to be given more flexibility in establishing real-time contact. In addition, recipients may routinely delay contact about known tasks, such as weekly status or expense updates, until a convenient time or place. Oftentimes, the preferences of recipients are at odds with the preferences of an enterprise or the implementation of a specific application. In those cases, recipients find creative ways to work around the application constraints, in order to satisfy their preferences, or find the enterprise's processes frustrating or even annoying.
A number of notification systems have been proposed or developed to enable applications to communicate with one or more recipients. Existing notification systems, however, are typically limited in media and function. For example, a notification system may only send an electronic mail message to a cellular telephone or pager. In addition, existing notification systems do not support flexible use of different communication infrastructures. The growth of wireless services, for example, such as those using the Wireless Access Protocol (WAP), described in WAP Forum, “Wireless Access Protocol 1.2.1,” June 2000, has led to the development of a number of notification and response services that contact only one device and thereby push and receive responses to web forms on cellular telephones.
The Session Initiation Protocol (SIP), as described, for example, in M. Handley et al., “SIP: Session Initiation Protocol,” RFC 2543, March 1999, provides a registry where users can be associated with particular devices by registering a SIP Uniform Resource Locator (URL) for the device. A number of SIP proxies exist that support the ability to contact the list of URLs recorded in the registry for a given user in parallel or sequentially to establish communication with the user. Call Processing Language (CPL), as described, for example, in J. Lennox and H. Schulzrinne, “CPL: A Language for User Control of Internet Telephony Services,” Draft RFC draft-ietf-iptel-cpl-05.txt, November 2001, is a language that is proposed for SIP proxies.
CPL allows users to specify in advance how to select a specific URL given characteristics of a SIP INVITE message (that is used in accordance with the SIP protocol to establish contact with the user), such as interpretations of the strings in the sender and target addresses or the subject of the INVITE. CPL also allows users to specify a timeout, so a sequential series of INVITE messages to specific devices can be tried when attempting to establish communication with the recipient. Moreover, SIP allows each SIP device or endpoint to specify the preferences of its user as a weighted list of media types and human languages. Senders are asked to provide, from the media types and human languages that they have available, the most highly weighted media type and human language. SIP and CPL do not provide support for interpreting the result of a communication, and taking different actions depending on that result. For example, once a telephone call is successfully answered, SIP and CPL do not discover if the user hung up the telephone or actually answered the request.
While sufficient techniques exist for specifying data flow or program flow through a system, the techniques that are available for specifying communication flow are typically rudimentary. A communication flow is the path of a request from requester to recipients. These existing communication flow techniques typically equate specifying a recipient for a request with some predefined method of contact such as sending an electronic mail message to a mailbox or a message to a pager. While a communication flow path is often thought of as a simple connection between two parties, modern communication capabilities enable a variety of communication flows. For example, a given communication flow can (i) contact recipients or devices used by a recipient in parallel or sequentially; (ii) wait for all recipients or just some of the recipients to respond to a request; or (iii) take a different direction when a communication error occurs.
A need therefore exists for a general technique for conveniently and accurately specifying the parameters of a communication flow, such as the recipients for a request, and how, when and where each recipient shall receive the request and how the responses direct further communication. A further need exists for a technique for specifying the parameters of a communication in a manner that captures and combines the requirements of applications and the preferences of recipients.